Rails: Prefer Devise for Authentication #736
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This might be controversial since we maintain [Clearance][], but I've found that I've only been on projects that use Devise during my time at thoughtbot. Although Rails introduced an [authentication generator][], I feel that Devise it still preferable for the following reasons: - It receives frequent security updates, whereas you're on your own with a generator. - It's widely adopted in the Rails community. - It has a [rich ecosystem]. [Clearance]: https://github.com/thoughtbot/clearance [authentication generator]: https://guides.rubyonrails.org/security.html#authentication [rich ecosystem]: https://github.com/heartcombo/devise?tab=readme-ov-file#extensions
vburzynski
reviewed
May 9, 2025
Comment on lines
+135
to
+136
| - Prefer [Devise][] over the [authentication generator][], due to its wide | ||
| adoption, rich [ecosystem][], and security maintenance. |
There was a problem hiding this comment.
- Could this be expanded to cover the set of architectural characteristics and project needs which would indicate Devise being a better choice and what set would indicate one should use Clearance?
- For example, a simple forms-over-data CRUD and simple REST based small Rails app might benefit more from Clearance. Clearance might support architectural characteristics like simplicity, maintainability, agility; as it's a more lightweight solution. It could also cost-less to implement if its feature set covers the needs of the app. Yet if an app is likely to expand beyond what Clearance can offer, the implementation team would need to weigh the cost of replacement or enhancing Clearance.
- on the other hand, an app with architectural characteristics that prioritize upgradeability, extensibility, configurability, and leverageability/reuse might want to choose Devise. Devise comes with a long list of third party extensions and a larger feature set. It's more commonly used across Rails applications. That large feature set comes with some complexity and challenges, but it's more ubiquitous in the Rails community.
- so there are tradeoffs to using one or the other.
- This guideline might also benefit from creating a "guideline page" to expound on the reasoning (including what's mentioned in the PR description).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This might be controversial since we maintain Clearance, but I've
found that I've only been on projects that use Devise during my time at
thoughtbot.
Although Rails introduced an authentication generator, I feel that
Devise it still preferable for the following reasons:
a generator.